Add Core Profile 11 Runner for Glassfish Embedded Web - #25446
Conversation
Having this file in the Uber jar was marking it as a bean archive and causing conflicts with the CDI Extensions adding the beans programatically
|
Hi, @Thihup, this PR now passes the usual Jenkins CI. That doesn't run the Core TCK though. What's the status? Does this runner run all the Core Profile TCKs? Do all tests pass? |
|
We have two Java files changes about a report, and the rest of the files is the usual copy of the ones in the platform-tck. We may think about whether we want to continuously copy these files, or just let them be at the platform-tck? |
This comment was marked as resolved.
This comment was marked as resolved.
|
It looks like this is just a work in progress and currently runs GlassFish Server and not Embedded. Turned it into a draft. |
|
It would be a great bennefit to have GlassFish Server run the core TCK as well. Maybe we can split this in 2 issues? One for Server and one for Embedded? Additionally there is the matter of copying all runners from https://github.com/jakartaee/platform-tck/tree/main/glassfish-runner or just leaving them there. |
|
See jakartaee/platform-tck#2715 A simple runner for GlassFish server |
|
Hi @pzygielo ! Could you please check Jenkins? |
I guess this can't start due to 
|
DeployerImpl.deploy(File, ...) returned normally even when the action report contained failures, so callers could not detect a failed deployment. Throw GlassFishException carrying the report message and failure cause instead. Extracted from #25446.
afterBean() unconditionally dereferenced the current invocation, which is absent when there is no default habitat or no active invocation (e.g. GlassFish Embedded). Return early in those cases instead of throwing. Extracted from #25446.
A bundled META-INF/beans.xml in the embedded-web uber jar alters CDI bean discovery of the assembled artifact. Exclude it from both unpacked dependency sets. Extracted from #25446.
6 participants
No description provided.